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Abstract — Mobile code based computing requires devel- 
opment of protection schemes that allow digital signature 
and encryption of data collected by the agents in untrusted 
hosts. These algorithms could not rely on carrying encryp- 
tion keys if these keys could be stolen or used to counterfeit 
data by hostile hosts and agents. As a consequence, both 
information and keys must be protected in a way that only 
authorized hosts, that is the host that provides information 
and the server that has sent the mobile agent, could modify 
(by changing or removing) retrieved data. The data man- 
agement model proposed in this work allows the information 
collected by the agents to be protected against handling by 
other hosts in the information network. It has been done 
by using standard public-key cryptography modified to sup- 
port protection of data in distributed environments with- 
out requiring an interactive protocol with the host that has 
dropped the agent. Their significance stands on the fact that 
it is the first model that supports a full-featured protection 
of mobile agents allowing remote hosts to change its own in- 
formation if required before agent returns to its originating 
server. 

Keywords — Assurance, Asymmetric ciphers, Cryptogra- 
phy, Data protection, Distributed networks, Information re- 
trieval, Mobile agents. 



I. INTRODUCTION 

GLOBAL-NETWORKING and world-wide communi- 
cations are changing computing concepts as were es- 
tablished some years ago. In the past, information was 
stored in trusted hosts where data was managed. In that 
case, it is easy to see that information security depends 
on the protection of the hosts themselves. Protection of 
hosts should be considered as a part of the operating sys- 
tems design and not as an add-on. In fact, to ignore last 
approach opens a wide variety of security holes in mod- 
ern computer systems [Q. In any case, hosts protection 
is more advanced that mobile code protection at present 
time. Distributed computing requires information to be 
managed in untrusted — and sometimes unknown — hosts 
in the network; consequently new data management mod- 
els must be developed for distributed environments j2| , || , 
[Q . Some protection schemes based in the use of Partial Re- 
sult Authentication Codes (PRACs) ensures a perfect for- 
ward integrity but does not assures backward integrity || . 
In these cases, the mobile agent carries the keys that will 
be used to protect the messages. Each key could be applied 
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to protect only one message being removed from the agent 
data area after using. Even forward integrity could be 
compromised. For example suppose that an agent follows 
a route H = {R u H 2 , . . . , H*,H m , . . . , H,-_i, H*, . . . , H„}, 
where both H* and H*, with i, j 6 {1,2,..., n} and i < j, 
are malicious hosts. The first hostile node in the route 
of the agent, that is H*, could provide a copy of the keys 
not removed from the mobile agent to the second mali- 
cious host, H*. The second host could use this informa- 
tion to counterfeit data provided by the hosts that apply 
these keys. This fact makes all the hosts in the subset 
H' = {Hj + i, H i+2 , . . . , Hj_i} C H vulnerable. The same 
problem will happen if the agent returns to the first ma- 
licious host later, showing that backward integrity cannot 
be assured in any case. 

The term message, as applied in this paper, stands for 
each block of information provided by the remote hosts to 
either other hosts or mobile agents. The word field identi- 
fies a chunk of the message itself. 

We want to note some differences that can be found be- 
tween mobile agents, mobile code and intelligent agents, to 
show in detail the problem that could be solved by using 
the threat described in our work: 

• Mobile agents. A mobile agent is a software object that 
have a code area and a data part. Both code and data 
areas will convey from a host to another one but the exe- 
cution thread will not be preserved. Mobile agents could be 
easily implemented by using serialization in programming 
languages as Java. 

• Mobile code. The most important difference between mo- 
bile agents and mobile code is that the latter allows the 
execution thread to be preserved when the agent goes from 
one host to the next one. As the execution thread will be 
changed in each host visited by the mobile code, to protect 
this area is not easy. 

• Intelligent agents. An intelligent agent is a software ob- 
ject that have the ability of process information retrieved 
autonomously. These agents does not require to be mobile. 
Intelligent agents are an active field of study in artificial in- 
telligence (AI) at present. 

A given agent could be classified in more than one of the 
groups described above. For example, a mobile agent could 
be programmed in a way that allows it to decide the route 
that it will follow by evaluating the information provided 
by the peer (remote) hosts, making it both a mobile and 
an intelligent agent simultaneously. 

The threat we propose in our work allows an agent to be 
protected against both malicious hosts and other agents. 
These hosts and agents could try to make unauthorized 
modifications on either the code area or the data space 
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of the agent or even to remove the information provided 
by other hosts. Our goal is to protect code and data ar- 
eas against both counterfeit and erasing. Our technique 
is based in the use of standard public-key encryption al- 
gorithms — also known as asymmetric ciphers — instead of 
symmetric ciphers. We will not propose nor recommend 
the use of a specific cipher over others in our work. 

We are not developing a protection algorithm for the 
execution thread. The execution thread is changed by each 
host where the mobile code arrives. As a consequence, it 
cannot be easily protected without using a logging system. 
In our opinion, encryption techniques could not be used to 
provide full protection of mobile code. 

II. NOTATIONAL CONVENTIONS 

In this section, we will introduce the notation used in 
our work. This notation will be applied to describe digital 
signature and encryption of data in both the agent server 
and the peer hosts. 

To describe the routes followed by the agents we will 
define the set H r = {HJ,H5, ... ,H£ p }, where r = 1,2,3,... 
and n r E N; this set will denote the n r hosts followed by 
the mobile agent released by a given agent server in its r-th 
route. In this set, ET[, where i E {1,2,..., n r } and r E N, 
determines the i-th host in the r-th route followed by the 
agent sent by the server S. 

Digital signature — Digital signature of data can be used 
to protect the information provided against counterfeit- 
ing and erasing by allowing, at the same time, to be read 
and authenticated by other hosts. It could be useful when 
agents are used in negotiation processes between hosts. In 
this case, only the private/public key pairs related with 
the remote hosts are used to protect the data stored in the 
agents allowing the information to be read and authenti- 
cated by any host or agent without a knowledge of the 
private-key used to digitally sign the message. We will de- 
note the digital signature of any given message using 
the expression: 



def 



pri H r 



MI 



(1) 



where M[ ■ and S[ ■ are the plain-text message and its sig- 
nature respectively, pri H r- identifies the private-key associ- 
ated with the host Hj*, and / stands for the digital signature 
algorithm applied to protect the information provided by 
the peer hosts against unauthorized modifications. 

The message M£ ■ can be authenticated by using the 
public-key associated with the i-th host in the agent route 
H r . That public- key may be available to any host. The 
security of the host H[ is not compromised by storing a 
copy of that public-key in a public-key server. As we will 
shown below, the use of certification authorities (CAs) to 
authenticate the public-keys itself is highly recommended. 
We must apply 



M lj = /p"ub Hr = /pub Hr [/prw [ M i,j] 



(2) 



where M[j and S[„- are the plain-text message and the digi- 
tal signature of M£ ■ again, pub H r stands for the public-key 



associated with the host H[ and / _1 identifies the digital 
signature authentication algorithm. 

Data encryption — A mobile agent based infrastructure 
would require an additional security level. Suppose that 
a server drops an agent that will retrieve information that 
must be covered to any host in the network except the 
server that has released the agent itself. In this case, data 
encryption should be used to hide the information stored 
in the agent data area. Data encryption requires the use of 
an additional key pair, the private/public key pair related 
with the agent server. Encryption of data requires the use 
of the public-key provided by the agent server to the re- 
mote hosts as a part of the mobile agent itself (pub s ), and 
the private-key associated with the remote host that pro- 
vides information to the agent. We will show below that 
the private/public key pair related with the server that has 
released the agent cannot be counterfeited without invali- 
dating the agent itself because it is a part of the code area. 
We will define the encryption process as: 



C[j — /pub s /pri Hr [Mij] 



(3) 



In this case, M£ • and C£ • are the plain-text message and 
its cipher-text respectively. The symbols pub s and pri H r- in 
equation @ stand for the public-key related to the agent 
server S and the private-key associated with the i-th host in 
the r-th route followed by an agent dropped by the server 
S respectively. In order to decrypt the cipher-text we must 
use the private- key associated with the agent server (pri s ), 
and the public-key provided by the peer host that has en- 
crypted the message M£ • : 



Mr 



f- 1 

J pubjjr- 
f- 1 

Jpub Hr 



/pri s /pub s /pri H r [M^] 



(4) 



The elements that appear in equation (Q) must be inter- 
preted in the same way as shown in other equations in 
this section. In this case, prig and pub s are, respectively, 
the private and the public keys for the agent server; pri H r 
and pub H r are the private and the public keys for the re- 
mote host H[ . The message that has been covered by using 
public- key cryptography is M[ •, that is the j-th message 
provided by the i-th host in the route followed by the agent, 
and the cipher-text itself is C^ . 

III. Code and Data Areas Protection 

Classical protection schemes do not allow a mobile agent 
to protect its own code area against unauthorized modifi- 
cation easily. Suppose that a server digitally signs the code 
of an agent before dropping it. This server must provide 
copies of the public-key used to other hosts. This public- 
key is required to authenticate the code area itself. This 
can be done easily by providing a copy of this key to a key- 
server or by using a CA. Obviously, the agent should be 
instructed to get this key showing at least the address of 
both the server that has released it and the host that stores 
a copy of the key. At this moment a malicious host, let us 
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say H['*, could change the agent code area and sign it by 
using its own private/public key pair. It is not difficult to 
prove that this modification will not be discovered by the 
remote hosts if the code is changed in such a way that the 
agent points to the new public-key. The hostile host only 
needs to assure that the signed code area provided by the 
agent server is recovered before the agent returns to the 
server that has dropped it. 

It is easy to see that code protection could not depend on 
classical cryptography even if the keys used to authenticate 
this area are certified and are provided by external trusted 
authorities. We need to develop a way to link the data 
provided by the peer hosts with the code part of the agent 
at the same time. This will allow us to protect data and 
code areas simultaneously. 

Other protection threats have been proposed in recent 
years. For example, the use of both code and data areas 
mess up techniques as described in [Q. In this reference, 
Hohl recommends the use of variable names that does not 
means anything. He also proposed that the code should not 
be modularized (i.e., it must be written without using sub- 
routines) and to choose a data representation that makes 
the program difficult to understand. This author proposed 
the use of variable recomposition techniques, conversion of 
compile-time control flow elements into run-time data de- 
pendent jumps and the insertion of dead code, that is code 
that will not be executed when the agent is running, into 
the agents. These techniques are based in mixing up the 
contents of the variables and creating new variables that 
contains a few bits of data of some of the original variables. 
These are recovered by changing the way the code of the 
agent handles the access to the variables. Another alterna- 
tive could be to develop a secure infrastructure for mobile 
agents || . The use of encrypted functions^ and execution 
environments (EE) with a fully separated interpreter^] has 
been proposed in ||, Q. At present, we do not have a way 
of protecting the code against unauthorized modification 
using encrypted functions because these techniques could 
not be easily applied to real agent systems. We need pro- 
tection schemes that do not rely on hiding the algorithms 
used in code handling or on building trusted environments 
for agent execution. Another problem is that the execution 
of encrypted functions requires the development of one-way 
homomorphic functions. These functions are unknown at 
present. 

In order to protect both the message provided by the 
remote host, that we have denoted by , and the mobile 

J By using mathematical functions with homomorphic properties. 
An example is the exponential function where the addition and mixed 
multiplication between x,y G C could be obtained without any ex- 
plicit knowledge of x providing exp [x] instead of x in: 



agent code area we propose that each host must obtain the 
next field: 



exp [x + y] 
exp [x ■ y] 



exp [x] ■ exp [y] 
(exp[x]) y , 



allowing us to represent the encrypted program as a polynomial. An 
important requeriment is that these functions should not be easily 
inverted. At present, there are not known one-way homomorphic 
functions. 

2 Where each agent have its own address space. 



Mcrc,, = crc [pub s ] + crc [/ pl , s [M^ odo ]] 



(5) 



provided by the agent server S 



where / pr i [M£ odc ] stands for the digital signature of the 
code area M£ odc . The code area includes both the agent 
code and an identification number (ID) for the agent. 
Therefore, this identification number is unique because it 
is generated from the agent server identificator, which is 
unique in the network (for example the IP-address in IPv4 
or IPv6 format of the agent server itself), and an agent 
number, which is unique for that server. In our case, we will 
obtain ID = server ro + agent ID . Obviously, / pr ; s [M£ ode ] 
could not be evaluated in the remote hosts. To obtain this 
field, a knowledge of the private-key associated with the 
server that has dropped the agent (prig) is required. This 
field must be provided as a part of the agent in a way that 
cannot be falsified. To manage it, a field F[ • must be added 
by the host H[ to the field M£ RC . . shown in equation (||). 
This field must change with each message provided in a way 
that it is unique for that host/agent pair. The code part 
must be authenticated by comparing its digital signature 
with the signature carried by the agent by each peer host 
before accepting it. The cyclic redundancy check (CRC) of 
both the public-key associated with the agent server and 
the signature of the agent code in (||) can be obtained by 
each remote host by using a hash algorithm. This informa- 
tion must be matched with the CRCs of both the public-key 
of the agent server and the digital signature provided as a 
part of the data area. 

In this section the term improved (as appears in both 
improved digital signature and improved data encryption) 
stands for digital signature and encryption processes that 
include information about the mobile agent code area. In 
fact, information about the code part of the agent will be 
included by each peer host in the field M^ RC . , as shown 
in equation @, allowing remote hosts to detect unautho- 
rized modifications of the code part of the agents. Partial 
data encryption will also provide a signed copy of the field 
M[, RC ... In this case, both the field Mg RC . . and the mes- 
sage Mjj will be digitally signed but only the message 
itself will be encrypted, allowing each host to detect code 
tampering but protecting information against reading by 
unauthorized hosts at the same time. 

Improved digital signature — In our opinion it is possible 
to protect both the agent code area and the information 
provided by the host itself simultaneously. To manage it, 
the field M£, RC . . must be used. This field must be stored 
as a part of each message provided to the mobile agents 
before being digitally signed: 



nr 



P rl HT 



M C r Ci 



M r ■ 



(6) 



this step assures data integrity while avoiding the possibil- 
ity to overwrite a new message provided by a remote host 
with an old one provided to another mobile agent in the 
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past. The information protected in this way is authenti- 
cated by applying the public-key pub H r- of the host that 
has signed it: 



M CRCij .+M^. = /-^ [sy 

= /pub Hr /pri H r 



(7) 



M 



CRCi 



M 



i,3 



Improved data encryption — The information about the 
code area of the mobile agent obtained by using (||) will 
be added to the message provided by the remote host. To 
encrypt a message for the agent server we must apply the 
next algorithm to the message itself: 



— /pub s Jpri H 



M 



CRCi,j 



m; 



1,3 



(8) 



In order to recover the full message, M CRC . . + M^ , the 
agent server should apply its own private-key, prig, and 
the public-key provided by the host that has encrypted the 
message, pub H r, obtaining: 



m; 



CRCj + M i,j — /pub Hr /pri s [^ij] 



(9) 



The main disadvantage of this method is that the code can 
be counterfeited in such a way that only the agent server 
knows that it has been falsified. If a part of C\ ^ is not 
encrypted, but is digitally signed, all the hosts in the route 
of the agent will have a way to determine whether the code 
area or other data in the agent have been falsified by any 
host. 

Partial data encryption — A better answer to the prob- 
lem of data encryption is to provide information publically 
about the CRC of both the public-key related with the 
agent server (pub s ) and the signature of the agent code, 
/pri s [M£ ode ]. It is possible to do it and, at the same time, 
to hide the message in such a way that only the authorized 
host (the agent server) could decrypt it. We propose to 
partially encrypt a digitally signed message using: 



C 



1,3 



fpr 



M 



CRCj 



/ P ub s [m: 



i,3i 



(10) 



assuring that the code area cannot be changed by a mali- 
cious host because each one can authenticate the CRC of 
the digital signature, provided by the agent server using 
(||) , and the public-key of that server simultaneously. This 
information can be verified by any host but the message 
M^- can only be decrypted using the private- key of the 
agent server, prig. We propose to apply the next set of 
equations to check the code and data areas of the agent 
and decrypt the message: 



M C R Ci ,+/pub s [My = /-^ [cy 



(ii) 



Mr 



/pi [/ P ub s [MIJ] . (12) 



The former equation (|ll|) can be used by any host because 
the public-key related with the i-th host in the r-th route 
followed by an agent sent by the server S (pub H r) is avail- 
able publically to all the hosts that need it. This equation 



will be required to check data and code integrity at the 
same time. Equation ( |l2|) is applied by the agent server 
using its own private- key, prig, to decrypt the information 
provided by the host H[, after checking the cipher-text by 
applying @. 

IV. Public-key Propagation 

One of the main goals of our work is to provide a threat 
that allows mobile agents to be protected against attacks 
like those described in Section V-A. We propose to use 
public-key ciphers, also known as asymmetric cryptosys- 
tems, instead of symmetric ciphers because the latter al- 
lows a simplified key management in distributed environ- 
ments. Public-keys can be shared between hosts in a net- 
work without requiring secure communication channels like 
these obtained using, for example, the Transport Layer 
Security (TLS) protocol. Detailed information about the 
TLS protocol can be found in |§j , |J . 

Some important requeriments must be considered in the 
development of a public-key propagation infrastructure for 
mobile agents: 

« Certification authorities. It is easy to see that uncertified 
public-keys cannot be trusted. It is not a good practice to 
send keys directly to the servers that need them. We need 
a network infrastructure that allows the nodes to assure 
what host owns each private/public key pair. For exam- 
ple middleman attack, the greatest known vulnerability of 
public- key based ciphers, can be avoided by using a trusted 
third party to verify and sign the keys transmitted over the 
network. 

• Non-interactive protocol. As pointed out it || a security 
model for mobile agents should conceive protocols that re- 
quire minimal interaction between the agent and the server 
that has sent it. The server may want to go off-line, conse- 
quently, the public-key should be provided by an indepen- 
dent host. Our threat allows the public-key related with 
the agent server (pubg) to be provided as a part of the 
agent. 

Our threat to protect mobile agents offers some impor- 
tant advantages too. 

• Secure communication channels are not required. This is 
a common advantage of public-key cryptography. As only 
public-keys are transmitted over the network untrusted 
communication channels can be established to share the 
keys. These keys cannot be used to falsify information or 
decrypt data provided to the agents. 

• We do not need to know what host owns each public-key. 
Obviously, this fact is only true if different access privileges 
are not assigned to each agent in function of the server that 
has released it. If different access permissions are required 
CAs must be used to authenticate the keys provided to the 
remote hosts and to assign the right access privileges to 
each agent server. 

Certified public-keys are required even if different access 
permissions are not assigned to mobile agents in function 
of the server that has dropped it. In fact, each peer host 
must identify other hosts in the network in soon a way that 
it does not allows host impersonation techniques. Trusted 
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third parties are needed to avoid well known threats like 
the middleman attack. We must consider that changing 
the public-keys carried by mobile agents — the public-keys 
associated with the agents servers — will invalidate data 
retrieved by the agents. If the information stored in the 
mobile agent data area is removed from the agent when 
this public-key is falsified other hosts will not have a way 
to determine that the agent have been modified without 
authorization. But this fact will be discovered by the agent 
server after the agent return. These keys does not require 
to be authenticated using a CA. Changing public-key for a 
given agent must be avoided once they have been provided 
to the route servers (RSs). 

As we noted in Section III, both code and data areas 
can be protected against counterfeiting and erasing by ma- 
licious hosts and agents. This can be achieved by adding a 
field Mp RCi . to each message retrieved by a mobile agent 
as presented in (^) . This field, Mq RC . . , will provide in- 
formation about both the code part of the agent and the 
public-key of its originating server. This field will be stored 
in such a way that it does not allow changing the code of 
the agent without invalidating it. 

Each agent have its own ID to avoid the possibility of 
overwriting the information provided by peer hosts with old 
data retrieved by other agents sent by the same server. This 
field is stored as a part of the code area. As a consequence, 
crc [/ p ri s [MJ od J] changes when new agents are dropped. 
Even obsolete information provided to the same agent in 
the past cannot be used to cover new data. Each host must 
generate a field, we called F£j , unique for each message. All 
these fields should be sent to the RSs: 



F[ = ID + F^+F^ 



-F r 



(13) 



where ID is the agent identification number mentioned 
above. The field F[ must be sent to RSs digitally signed 
by applying: 

= /pri Hr [F[] , (14) 



or 

^fields; 



using the private/public key pair for the host that provides 
that information. Any host can check each message pro- 
vided by H[ by using the F^- fields, where i 6 {1,2,..., n r } 
and j = 1,2,..., m£, stored in F[ 
authenticated by using: 



Those fields must be 



— ^pub Hr [^fields J — /pub H r /pri H t Fi ] 



(15) 



To assure the integrity of the message F[ each RS should 
send a random message to the host that wants to provide 
a new (or an updated) message F£. This random message 
must be digitally signed and returned to the RS that re- 
leased it. The random message signature must be checked 
before the RS accepts F[. In other case, a malicious host 
can provide an obsolete message F['* to the RSs overwrit- 
ing the mobile agent data area with old information corre- 
sponding to the false message F['* simultaneously. 



V. Attacks against Mobile Agents 
Infrastructures 

In this section we classify the attacks that is possible 
to try against the mobile agents and other hosts in the 
network. We show how our protection threat allows us to 
protect the agents and, in some cases, even remote hosts 
against these attacks. 

A. Attacks against Mobile Agents 

The main goal of our investigation is to protect the mo- 
bile agents against both malicious hosts and other agents 
that can counterfeit the code part and/or data areas of the 
agents. These hostile agents and hosts can try to remove 
information carried by the agents too. As noted, these at- 
tacks could arrive from both other agents and the hosts 
where the agents are stored. In both cases, we will protect 
the agent using the same threat. 

A.l Attacks against the Code Part 

As we shown in Section III the agent code area can be 
protected by adding two CRCs to each message provided 
by the peer hosts. These CRCs provides information that 
allows peer hosts to authenticate both the public-key as- 
sociated with the agent server and the digital signature of 
the code area of the agent, that has been provided by the 
agent server itself. These fields must be matched with each 
message stored in the data area by the hosts followed in the 
agent trip, as appears in the set H r . At last, each host au- 
thenticates the code area of the agent too before running 
it using that digital signature previously checked. As both 
the CRC related with the digital signature of the code area 
and the CRC for the public-key of the agent server cannot 
be changed during agent trip, but the latter is unique for a 
given agent, data area is protected at the same time. As a 
consequence, the attacks described below can be avoided. 

A. 2 Attacks against the Data Area 

The attacks against the information carried by mobile 
agents can be classified in three groups: (i) attacks trying 
to erase data carried by the agents (also known as a mobile 
agent "brainwashing" in bibliography), (ii) attacks trying 
to falsify data provided by other hosts and (Hi) attacks 
trying to uncover non-public information carried by the 
agents. 

Removing information — To avoid a mobile agent "brain- 
wash" each host must provide information about the num- 
ber of messages stored in a particular agent to the RSs 
as we described in Section IV. It is easy to see that all 
the information needed to protect the data area cannot be 
stored in the agent. Suppose for example that a mobile 
agent carries a set of signed messages 

*r\r r or or nr nr or nr 

u — °l,2i ' ' ' ' a l,m£) °2,1) a 2,2i ■ ■ ■ > a 2,m£i ■ • • ) 

Sv or or Q 

i,l i ^i,2; ■ ■ • ! ) • • • i ^<,f?»J > • • • j 

Sn r ,l> S^ ri 2) • • • j ^n r ,m^, r } ' 0-®) 

in its data area. The set T> r in (|l^) stands for the signed 
data area of the r-th agent released by a server. All the 
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messages are signed in a way that only the hosts that has 
provided these messages can change its contents. If the RSs 
do not provides information about the number of messages 
given by each host to the agent server or, more generally to 
other hosts that requests it, any hostile node (any malicious 
host in the network) can remove a message, let us say S^- 
where i £ {1,2, ...,n r } identifies the host that provides 
the message removed and j £ {1,2,..., m[} stands for the 
j-th message provided by that host. In this case, the set of 
messages carried by the agent, V r , is changed to 
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without invalidating the data area. In this case, the set T> r '* 
is the falsified data area of the agent. The same problem 
happens when encryption is used if the number of messages 
carried by a mobile agent is not provided to the RSs in any 
way. In this case the encrypted data area of the agent: 
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can be modified by removing one of the cipher-texts pro- 
vided by the remote hosts. For example, the cipher-text 
that corresponds to the j-th message provided by the i-th 
host in the agent route can be erased by changing the agent 
data area to: 
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Even if information about the number of messages carried 
by the agent is provided in a way that an hostile peer host 
cannot change it, data area can be altered by overwriting 
it with a bit-copy of an old data area. 

To avoid attacks based in the techniques described above 
we propose to send information about the number of mes- 
sages provided to the agent to the RSs shown in the code 
area of the mobile agent itself. These hosts cannot be 
changed without invalidating the agent itself. A copy of 
the fields F£ ■, as shown in equation (|^), is all the informa- 
tion needed to manage it; in fact, these fields are required 
to authenticate data provided by each host visited by the 
mobile agent as shown above. 

Counterfeit of data — Even if data have been digitally 
signed or encrypted information provided can be falsified. 
As noted above, data area can be protected against "brain- 
washing" by storing information about the amount of mes- 
sages provided by each host visited by the agent in sep- 
arated hosts. We need a way to protect the information 
provided by peer hosts to the agent against being over- 
written with old signed data provided by those hosts in 
the past. In Section III we propose to link data provided 
as a part of the agent, the fields in Mq RC . . as shown in 



(||), with each messages retrieved by the agent. If this field 
is not included any hostile host can change the data area 
of the agent as appears in (|l6|), overwriting a valid signed 
message M£ ■ with an old message signed by the same host 
using the same private/public key pair, let us say M['*: 
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The same problem happens with encrypted messages if the 
field Mp RC _ . , obtained by applying ([|) , is not provided as 
a part of the messages. In this case, the encrypted data 
area of the mobile agent in (jlT]) can be counterfeited by 
changing one of the cipher-texts provided by the remote 
hosts, for example the message can be changed to C[ 
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To avoid information provided by peer hosts to be overwrit- 
ten by using a bit-copy with old signed data obtained in 
the same trip we propose to add another field to M CRC . . . 
This field is introduced in Section III. Each host can pro- 
vide a field in each message. We denoted this field as F^-. 
This field is changed when the remote host wants to sign 
or encrypt a new message for the agent. This field will 
be provided to the RSs and must be matched against the 
copies stored in F^ by each host that wants to check data 
and code integrity. Each host visited by the agent provides 
a set of fields F£ •, where j = 1, 2, . . . , m£ to the RSs as 
presented in (|l3|). 

Cryptanalysis — In our work we propose to protect data 
provided by using standard cryptographic techniques that 
can be attacked by using cryptanalysis^. We are not mak- 
ing assumptions about the encryption algorithms used to 
cover data nor the keys length that may vary in function 
of the security requirements. As noted in |io|| , the fact 
that public-key based ciphers allows predictable patterns 
to survive the encryption process making this technology 
vulnerable to cryptanalysis is well known to cryptanalysts; 
as a consequence, standard compression techniques should 
be applied before encryption to increase data security. 

Middleman attack — The man-in-the-middle attack is 
probably the greatest known vulnerability of asymmetric 
cryptosystems. Mobile agent based infrastructures can be 
attacked by using a middleman attack variant. In this case, 
a malicious host will intercept both the public-key send to 
the RSs by the remote host and the agent itself. This host 
will generate a private/public key pair to falsify data pro- 
vided by that host and provide a copy of the false public- 
key to the RSs. To avoid the attacks based on this threat 
the use of CAs to verify and sign the keys used by the hosts 
to protect its own data is recommended. 

3 Two powerful techniques to attack ciphers, known as differential 
and linear cryptanalysis, were elaborated and are being currently 
used. The former was developed by Adi Shamir and Eli Biham of 
Technion Israel Institute of Technology. The latter was introduced 
by Mitsuru Matsui of Mitsubishi Electric Corporation. 
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A. 3 Attacks against the Agents itself 

The mobile agents can be attacked in a way that do not 
require to modify either the code area or the data part 
of the agents. The main goal of these attacks can be to 
damage the agent infrastructure itself by destroying the 
agents or releasing new agents instead of the original one. 

Removing agents — Any malicious host can remove the 
agents when arrive to it. There are no- way to avoid this 
attack against the agents but or protection threat allows 
other host to try to discover what host has killed the agent 
by requesting information about the route followed by the 
agent. 

Releasing new agents — A hostile host can remove all the 
information stored in the mobile agent and change the code 
area. Modifying the code area requires gathering a fake pri- 
vate/public key pair for the agent server but now it is possi- 
ble because all the M£ RC . . fields have been removed from 
the data area of the agent. The new private/public key 
pair can be used to sign a modified code area of the agent. 
This fact can be discovered, at least, by the server that 
has released the agent when it comes back. If other hosts 
have a copy of the public-key of the agent server, either ob- 
tained by other channels or sent in the past, these hosts can 
discover the unauthorized modification of the agent too. 

B. Attacks against Peer Hosts 

Our goal is to protect mobile agents against attacks from 
both peer hosts and other agents. We are not trying to 
develop a threat to protect hosts against malicious agents. 
Attacks against remote hosts could be initiated from both 
agents and hosts. 

The code area protection allows an agent to be protected 
against malicious changes that could affect how it works. 
At the same time, the code protection allows a host to 
be protected against Denial of Service (DoS) attacks by 
agent cloning in the sense that the number of clones could 
be easily verified by using the agent identification number 
described above. This allows a host to protect itself by 
controlling the resources provided to the agents in a per- 
agent basis. The agent identification number allows a host 
to identify the number of clones of a given agent. 

The code protection threat proposed in our work do not 
permits a hostile host to change the code part of an agent 
provided by an agent server without invalidating it but, 
obviously, this host could release its own malicious agents. 

VI. Conclusions 

Mobile agents are an extremely vulnerable piece of soft- 
ware because they are executed in untrusted environments. 
Both code and data areas must be protected against ma- 
licious hosts and agents. The former requires techniques 
that does not allow a malicious host to hide the identity 
of the real agent owner. The latter requires information 
provided by remote hosts to be protected against counter- 
feit and erasing. The main advantages of the algorithm 
proposed in this paper are that: 

• Secure communication channels are not required allowing 



a mobile agent to be transmitted over untrusted channels 
and even stored in malicious hosts where the agent will be 
shown as plain-text even if trusted communication channels 
between hosts are established. 

• Both code and data areas are protected against counter- 
feit and erasing; consequently, mobile agents are a more 
secure and robust platform. 

• Each host could change its own information when re- 
quired. This allows a host to update information provided 
permitting the development of more sophisticated agent- 
based applications, where negotiation between agents and 
hosts is required. 

We hope that our protection scheme allows mobile agent 
based infrastructures to be protected against other attacks 
based on threats not covered in this article or even unknown 
at present. If this can be achieved, our threat could be a 
good design principle for mobile agent based information 
networks. 
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